I corresponding to the particular devices on each card. Referring to Fig. 8, slave MCDs 

39a-39n search PMD file 48 in memory 40 on central processor 12 for a match with their 

line card type and version number. Just as the master MCD 36 found the name of the 

MKI executable file for each line card in the PMD file, each slave MCD 39a-39n reads 

5^ the PMD file to learn the names of all the device driver executable files associated with 

each line card type and version. The slave MCDs provide these names to the slave SRMs 

on their boards. Slave SRMs 37a-37n then download and execute the device driver 

executable files (DD.exe) 56a-56n from memory 40. As one example, one port device 

o 

driver 43a-43d may be started for each port 44a-44d on line card 16a. The port drrfgp x 

o 0 

( 0 and port are linked together through the assigned port PID number. o ^ 

In order to understand the significance of the PMD file (i.e., metadata), note that theg § 
MCD software does not have knowledge of board types built into it. Instead, the M<§? 
parameterizes its operations on a particular board by looking up the card type and version 
/ ^number in the PMD file and acting accordingly. Consequently, the MCD software does 
not need to be modified, rebuilt, tested and distributed with new hardware. The changes 
required in the software system infrastructure to support new hardware are simpler 
modify logical model 280 (Fig. 3) to include: a new entry in the PMD file (or a new PMD 
file) and, where necessary, new device drivers and applications. Because the MCD 
2 0 software, which resides in the kernel, will not need to be modified, the new applications 
and device drivers and the new DDL files (reflecting the new PMD file) for the 
configuration database and NMS database are downloaded and upgraded (as described 
below) without re-booting the computer system. 

Z*>~ Network Management System (NMS): 

Referring to Fig. 9, a user of computer system 10 works with network management 
system (NMS) software 60 to configure computer system 10. In the embodiment 
^ ^ described below, NMS 60 runs on a personal computer or workstation 62 and 

ZP\ communicates with central processor 12 over Ethernet networl^^(out-of-band). 

Instead, the NMS may communicate with central processor 1 2 over data path 34 (Fig. 1 , 
in-band). Alternatively (or in addition as a back-up communication port), a user may 
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/ communicate with computer system 10 through a terminal connected to a serial line 66 
connecting to the data or control path using a command line interface (CLI) protocol. 
Instead, NMS 60 could run directly on computer system 10 provided computer system 10 
has an input mechanism for the user. 



k NMS 60 establishes an NMS database 61 on work station 62 using a DDL file 
corresponding to the NMS database and downloaded from persistent storage 21 in 
computer system 10. The NMS database mirrors the configuration database through an 
active query feature (described below). In one embodiment, the NMS database is an 

(0 Oracle database from Oracle Corporation in Boston, Massachusetts. The NMS and 



C( central processor 12 pass control and data over Ethernet fusing, for example, the Java 
Database Connectivity (JDBC) protocol. Use of the JDBC protocol allows the NMS to 
communicate with the configuration database in the same manner that it communicates 
with its own internal storage mechanisms, including the NMS database. Changes made 
to the configuration database are passed to the NMS database to insure that both 
databases store the same data. This synchronization process is much more efficient and 
timely than older methods that require the NMS to periodically poll the network device to 
determine whether configuration changes have been made. In these systems, NMS 
polling is unnecessary and wasteful if the configuration has not been changed. 
Additionally, if a configuration change is made through some other means, for example, a 
command line interface, and not through the NMS, the NMS will not be updated until the 
next poll, and if the network device crashes prior to the NMS poll, then the configuration 
change will be lost. In computer system 10, however, command line interface changes 
made to configuration database 42 are passed immediately to the NMS database through 
the active query feature ensuring that the NMS is immediately aware of any configuration 
changes. 

Typically, work station 62 is coupled to many network computer systems, and NMS 60 is 
used to configure and manage each of these systems. In addition to configuring each 
system, the NMS also interprets data gathered by each system relevant to each system's 
network accounting data, statistics, and fault logging and presents this to the user. 
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